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(54) Controlling access to services between modular applications 



(57) The present invention provides a method and 
an apparatus for providing a first computer program 
module (122) with the ability to access a service from a 
second computer program module (112). The method 
includes receiving the first computer program module 
(12) for example, at a third party computer system 
(140), and determining whether the first computer pro- 
gram module has been digitally signed by an authority 
(204) having power to confer access for the service. If 
so, the method provides the first computer program 
module (122) with access to the service. A variation on 
this embodiment includes verifying that the first compu- 
ter program module (122) includes a chain of certifi- 
cates establishing a chain of authorisation for the 
service. This verification process includes verifying that 
a first certificate in the chain is signed by an entity (400) 
that is originally authorised to confer access for the 
service, and verifying that subsequent certificates in the 
chain are signed by entities (430,450) that have been 
delegated authorisation to confer access for the service. 
In a further variation on the above embodiment, the act 
of providing the first computer program module with 
access to the service, includes providing the first com- 
puter program module (122) with a permit that allows 
the first computer program module (122) to perform a 
restricted set of operations on the service. 
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Description 
BACKGROUND 

[0001] The present invention relates to protection 
mechanisms in computer systems. More specifically, 
the present invention relates to a method and an appa- 
ratus for controlling access to services. 
[0002] Programming languages such as the Java™ 
programming language (developed by SUN Microsys- 
tems, inc. of Palo Alto. California) and associated sup- 
porting interfaces presently provide a reliable and 
secure infrastructure to support the transfer of an appli- 
cation across a computer network, and to run the appli- 
cation on a wide range of computing platforms. 
Because of developments such as Java, it is becoming 
increasingly common to load an application, such as a 
Java applet, from a remote server onto a local machine, 
and to execute the application on the local machine. 
[0003] However, present computing systems are not 
designed to allow computer applications from different 
vendors to interact with each other in a controlled way 
so that the applications can work together to accomplish 
a given task, in particular, these systems do not facili- 
tate sharing of data and functions. For example, it may 
be useful for a tax application to access capital gains 
information from a home brokerage application. How- 
ever, the home brokerage application needs to protect 
the privacy of the customer's portfolio. Hence, the tax 
application cannot be given unrestricted access portfo- 
lio data from the home brokerage application. 
[0004] Additionally, software vendors may want to 
enforce contractual arrangements between comple- 
mentary applications. For example, a home brokerage 
application may want to tap into historical pricing infor- 
mation supplied by an application from a financial insti- 
tution. This arrangement would be facilitated if the 
vendor of the home brokerage application would estab- 
lish a contractual arrangement with the financial institu- 
tion that allows the home brokerage application to 
access the historical pricing information. 
[0005] Unfortunately, present computing systems lack 
any mechanism for facilitating and controlling access to 
services provided by other applications. In particular, 
with present systems it is not possible to identify appli- 
cations that have been granted rights to access serv- 
ices from other applications, nor to control what 
services a given application can have performed. 

SUMMARY 

{0006] The present invention provides a method and 
an apparatus for providing a first computer program 
module with the ability to access a service from a sec- 
ond computer program module. The method includes 
receiving the first computer program module ~ for 
example, at a third party computer system, and deter- 
mining whether the first computer program module has 



been digitally signed by an authority having power to 
confer access for the service. If so, the method provides 
the first computer program module with access to the 
service. A variation on this embodiment includes verify- 

5 ing that the first computer program module includes a 
chain of certificates establishing a chain of authorization 
for the service. This verification process includes verify- 
ing that a first certificate in the chain is sighed by an 
entity that is originally authorized to confer access for 

io the service, and verifying that subsequent certificates in 
the chain are signed by entities that have been dele- 
gated authorization to confer access for the service. 
[0007] In a further variation on the above embodiment, 
the act of providing the first computer program module 

is with access to the service, includes providing the first 
computer program module with a permit that allows the 
first computer program module to perform a restricted 
set of operations on the service. 
[0008] In another variation on the above embodiment, 

20 the first computer program module and the second 
computer program module can interact with each other 
on a third party computer system. In this case, the first 
computer program module is transferred from a first 
server to the third party system, and the second compu- 

25 ter program module is transferred from a second server 
to the third party system. This allows the first computer 
program module and the second computer program 
module to interact with each other on the third party sys- 
tem. 

30 

BRIEF DESCRIPTION OF THE FIGURES 
[0009] 

35 FIG. 1 illustrates a number of computer nodes cou- 
pled together through a network 130 in accordance 
with an embodiment of the present invention. 
FIG. 2 illustrates the process of receiving access to 
a service in accordance with an embodiment of the 
40 present invention. 

FIG. 3 illustrates part of the structure of client code 
module 122 from FIG. 1 in accordance with an 
embodiment of the present invention. 
FIG. 4 illustrates how authority to access a service 
45 is transferred between different entities using a 
chain of certificates in accordance with an embodi- 
ment of the present invention. 
FIG. 5 is a flow chart illustrating how authorization 
to access a service is propagated, and is ultimately 
so used gain access to the service, in accordance with 
an embodiment of the present invention. 

DETAILED DESCRIPTION 

55 [0010] The following description is presented to ena- 
ble any person skilled in the art to make and use the 
invention, and is provided in the context of a particular 
application and its requirements. Various modifications 
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to the disclosed embodiments will be readily apparent to 
those skilled in the art, and the general principles 
defined herein may be applied to other embodiments 
and applications without departing from the spirit and 
scope of the present invention. Thus, the present inven- 
tion is not intended to be limited to the embodiments 
shown, but is to be accorded the widest scope consist- 
ent with the principles and features disclosed herein. 
[001 1 J For purposes of this detailed disclosure the fol- 
lowing terminology is used. (1) A "Java Archive file" can 
be a file containing modular bodies of Java™ code in 
addition to resources, such as graphics or audio files. 
(2) A "computer readable storage medium" can be any 
device or medium that can store code and/or data for 
use by a computer system. This includes, but is not lim- 
ited to, magnetic and optical storage devices such as 
disk drives, magnetic tape, CDs (compact discs) and 
DVDs (digital video discs), or alternatively, computer 
instruction signals embodied in a carrier wave. (3) A 
"computer program module" can be a module including 
a collection of instructions that can be executed by a 
computer. These instructions may comprise an entire 
computer program, or merely a piece of a computer pro- 
gram. A computer program module often exists in a 
form that facilitates downloading onto a computer sys- 
tem across a computer network. For example, a compu- 
ter program module may take the form of a Java™ 
Applet. (4) An "entity" can be a human being, a compu- 
ter program or a computer system, that has the power to 
confer access rights for a service, and optionally the 
ability to delegate such power to other entities. (5) A 
"service" can include a single service or a plurality of 
services. Therefore, the act of conferring access for. a 
service can also confer access to a plurality of services. 

Computer System 

[001 2] FIG. 1 illustrates a number of computer nodes 
coupled together through a network 130 in accordance 
with an embodiment of the present invention. In FIG. 1, 
servers 110 and 120 are coupled to third party system 
1 40 through network 130. A computer node can be any 
computation device that can be coupled to a computer 
network. A computer node may include, but is not lim- 
ited to, a personal computer, a workstation, a main- 
frame computer, a portable computer or a device 
controller. Network 130 generally refers to any type of 
wire or wireless link between computers, including, but 
not limited to, a local area network, a wide area network, 
or a combination of networks. In one embodiment of the 
present invention, network 130 includes the Internet 
Servers 110 and 120 can be any nodes on a computer 
network including a mechanism for servicing requests 
from a client for computational or data storage 
resources. Third party system 140 may be any node a 
computer network communicating with servers 110 and 
120 that is able to download code and/or data from 
servers 110 and 1 20. 



[0013] In the embodiment illustrated in FIG. 1, server 
110 contains server code module 112, and server 120 
contains client code module 122. For purposes of this 
detailed disclosure, a server code module is a module 

s including code that provides a service to a client code 
module, and a client code module is a module including 
code that requests a service from a server code mod- 
ule. Server code module 1 12 and client code module 
122 include modular pieces of code that can operate 

10 together on third party system 1 40. The dashed lines on 
FIG. 1 represent server code module 112 and client 
code module 122 being downloaded onto third party 
system 140 across network 130. This downloading 
process can take place in a number of ways. In one 

i 5 embodiment of the present invention, server 110 
includes a web site that can be accessed by a user on 
third party system 140 to download server code module 
112 onto third party system 140. Correspondingly, 
server 120 includes a web site that can be accessed by 

20 a user on third party system 140 to download client 
code module 122 into third party system 140. In another 
embodiment, server code module 112 and client code 
module 122 are not downloaded across network 130. 
Instead, they are transferred from servers 110 and 120, 

25 respectively, to third party system 1 40 by way of compu- 
ter storage media, such as a computer disk. 
[001 4] Gnce server code module 1 1 2 and client code 
module 122 are located on third party system 140, they 
can be integrated to work together as is illustrated in 

30 FIG. 1 . For example, in providing a service to client code 
module 122, server code module 112 might retrieve 
data from a database for client code module 1 22. Alter- 
natively, server code module 112 might perform a com- 
putational operation for client code module 122. This 

35 integration process may involve determining whether 
client code module 122 has been conferred the right to 
access services from server code module 112. In the 
reverse direction, this process may involve determining 
whether server code module 112 has been conferred 

40 the right to access services from client code module 
122. 

Access Model 

45 [0015] FIG. 2 illustrates the process of accessing a 
service in accordance with an embodiment of the 
present invention. FIG. 2 illustrates interactions 
between server gate 202, system 204 and client code 
module 122 (from FIG. 1). Server gate 202 includes an 

so access mechanism that controls access to services pro- 
vided by server code module 112 (from FIG. 1). In one 
embodiment of the present invention, server gate 202 is 
located within server code module 112 on third party 
system 140. In another embodiment, server gate 202 is 

55 located within server 110 itself, and is accessed via 
communications across network 130. System 204 
includes a mechanism for establishing that client code 
module 122 is properly authorized to access services 
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provided by server code module 112. To this end, sys- 
tem 204 is implemented in a number of ways. In one 
embodiment, system 204 is implemented by code that 
is part of third party system 140. In another embodi- 
ment, system 204 may be implemented as part of 
server code module 112 within third party system 140. 
[0016] The process illustrated in FIG. 2 operates as 
follows. Client code module 122 is assumed to already 
exist within third party system 1 40. In order to access a 
desired service, client code module 122 requests a 
"ticket" for a "role" to access a collection of services 
from server code module 112. (For purposes of this 
detailed disclosure, a ticket is an object that cannot be 
forged that indicates that the holder of the object has 
been signed to use certain services.) A role defines a 
set of operations to be performed by server code mod- 
ule 112. Certain roles may be more limited than other 
roles. For example, if server code module 1 12 maintains 
a computer file system, one role may include only the 
operation of reading a file from the file system. Another 
more powerful role may include the operations of read- 
ing, writing and deleting files from the file system. 
[001 7] In response to the request, system 204 exam- 
ines client code module 122 to determine if client code 
module 122 includes proper authorization for the role. In 
one embodiment of the present invention, this examina- 
tion includes examining a certificate chain 310 (illus- 
trated in FIG. 3) to ensure that certificate chain 310 has 
been properly signed by a chain of authorities. This 
process is described in more detail below with reference 
to FIGs. 3-5. 

[001 8] If client code module 1 22 is properly authorized 
for the role, system 204 issues a ticket for the role, and 
this ticket is given to client code module 122. Next, client 
code module 122 passes the ticket to server gate 202. 
Server gate 202 checks the ticket to ensure that the 
ticket is valid, if it is valid, server gate 202 sends a per- 
mit for the service to client code module 122. (For pur- 
poses of this detailed description, a permit is a proxy or 
a capability giving a holder of the permit access to a 
service or a group of services.) This permit allows client 
code module 122 to access the services defined by the 
role. In one embodiment of the present invention, this 
permit is an object defined within an object-oriented 
programming system. This object allows client code 
module 122 to perform a set of methods that comprise 
the role. After the permit is sent, server gate 202 invali- 
dates the ticket, so that it cannot be used again. Since 
client code module 122 remains in possession of the 
permit, client code module 122 will be able to access 
services using the permit, and hence, no longer needs 
the ticket. 

Client Code Module 

[0019] FIG. 3 illustrates part of the structure of client 
code module 122 from FIG. 1 in accordance with an 
embodiment of the present invention. Client code mod- 



ule 122 includes certificate chain 310 and client code 
320. Certificate chain 310 includes a chain of certifi- 
cates that establishes a chain of authorization for the 
service. The first certificate in the chain is signed by an 

5 entity that is originally authorized to confer access for 
the service, and subsequent certificates in the chain are 
signed by entities that have been delegated authoriza- 
tion to confer access for the service from preceding enti- 
ties in the chain. 

10 [0020] For purposes of this detailed disclosure, a cer- 
tificate is a signed electronic document that certifies that 
something is true. A certificate typically indicates that 
someone has ownership of a public key. In the present 
invention, a certificate can indicate that an entity can 

is have access to services represented by a key. A certifi- 
cate may include the identity of a signing authority as 
well as a digital signature produced with a private key 
(that can be validated with a corresponding public key). 
For example, one certificate format is defined under the 

20 X.509 standard. 

[0021 ] For purposes of this detailed disclosure, a dig- 
ital signature is a value derived from a file using a secret 
such that it can be demonstrated that the value was 
derived using the secret, wherein the secret is known 

25 only to the signer. A digital signature may take the form 
of a message digest produced by the key and appended 
to the file, or may take the form of a transformation of 
data within the file using the key. A digital signature may 
also take the form of a message digest encrypted by the 

30 private key of a public key private key cryptography sys- 
tem. 

[0022] For example, in the illustrated embodiment cer- 
tificate chain 310 includes certificate-1 312, certificate-2 
314 and certificate-N 316. A server code owner initially 

35 starts with a private key zero. In order to pass along 
authority for a role, the server code owner generates a 
certificate-1 312 and an associated public key private 
key pair, the private key being private key one. The 
server code owner signs certificate-1 312 with private 

40 key zero and passes certificate- 1312 along with the 
corresponding private key one to a first intermediary. 
The first intermediary generates certificate-2 314 along 
with a corresponding public key private key pair, includ- 
ing private key two. The first intermediary signs certif i- 

45 cate-2 314 with private key one and passes certificate-2 
314, along with the associated private key two and all 
previous certificates in the chain, to a following interme- 
diary. This pattern continues up the chain until a final 
intermediary signs certificate-N 316 with private key N- 

so 1 and passes the certificate-N 316, along with corre- 
sponding private key N and all previous certificates in 
the chain, to a client code owner. The client code owner 
uses private key N to sign client code 320, and then 
generates client code module 122, which includes cer- 

55 tificate chain 310 and client code 320. 

[0023] Hence, client code module 1 22 includes a ver- 
ifiable chain of certificates 310 signed by intermediaries 
from the server code owner to the ultimate client code 
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owner. Certificate chain 310 can be verified by using the 
public keys to verity that certificates in the chain are 
properly signed with their corresponding private keys. 

Delegation of Authority 

[0024] FIG. 4 illustrates how authority to access a 
service is delegated between different entities using a 
chain of certificates in accordance with an embodiment 
of the present invention. In this example, server com- 
pany 400 delegates authority to access data associated 
with a server code module, such as server code module 
112 in FIG. 1. This server code module is distributed to 
various third party systems, and can interact with prop- 
erly authorized dient code modules on these third party 
systems- Alternatively, the server code module can 
interact with client codes modules on computer systems 
belonging to either server company 400 or to the own- 
ers of the client code modules. 

[0025] In the example illustrated in FIG. 4, server com- 
pany 400 does the following. First, server company 400 
generates a public/private key pair, including private key 
zero. Next, server company 400 generates server code 
460, which checks to see that client code modules 
include a chain of certificates, including a root certificate 
signed with private key zero. Second, server company 
400 generates a certificate and a public/private key pair 
for each intermediary or client company that it desires to 
delegate authority to. Third, it sends the certificate 
signed with private key zero and the private key associ- 
ated with the certificate to the intermediary or client 
company. In the illustrated example, server company 
400 sends certificate X 404 (signed with private key 
zero) and private key X 402 to client company X 430. 
Server company 400 additionally sends certificate Y 
420 (signed with private key zero) and private key Y 418 
to intermediary Y 450. 

[0026] In the example illustrated in FIG. 4. client com- 
pany X 430 generates certificates and public/private key 
pairs for each of three projects, and passes the certifi- 
cates and associated private keys to entities within cli- 
ent company X 430 that are responsible for producing 
three different client code modules. In particular, client 
company X 430 passes certificate X1 408 (signed with 
private key X) and private key X1 406 to project X1 432. 
Client company X 430 also passes certificate X2 412 
(signed with private key X) and private key X2 410 to 
project X2 434. Client company X 430 additionally 
passes certificate X3 416 (signed with private key X) 
and private key X3 414 to project X3 436. 
[0027] Next, each project within client company X 430 
creates a code module. In particular, project XI 432 cre- 
ates a code module 438 for project X1 . This code mod- 
ule includes a chain of certificates, including certificate 
X 404 (signed with private key zero) and certificate X1 
408 (signed with private key X 402). Code module 438 
also includes code (not shown) that is signed with pri- 
vate key X1 406. Project X2 434 creates code module 



440 for project X2. This code module includes a chain of 
certificates, including certificate X 404 (signed with pri- 
vate key zero) and certificate X2 412 (signed with pri- 
vate key X 402). Code module 440 also includes code 

5 (not shown) that is signed with private key X2 410. 
Project X3 436 creates code module 442 for project X3. 
This code module includes a chain of certificates, 
including certificate X 404 (signed with private key zero) 
and certificate X3 416 (signed with private key X 402). 

10 Code module 442 also includes code (not shown) that is 
signed with private key X3 414. 
[0028] In the example illustrated in FIG. 4, intermedi- 
ary Y 450 generates a certificate Z 424 and a public, pri- 
vate key pair, including private key Z 422. Intermediary 

15 Y 450 signs certificate Z 424 using private key Y 418 
and passes certificate Z 424 (signed with private key Y 
418) along with private key Z 422 to client company Z 
452. 

[0029] Client company Z 452 creates code module 
20 454 for project Z, which includes a chain of certificates, 
including certificate Y 420 (signed with private key zero) 
and certificate Z 424 (signed with private key Y 418). 
Code module 454 also includes code (not shown) that is 
signed with private key Z 422. 

25 

Delegation and Aut horization Process 

[0030] FIG. 5 is a flow chart illustrating how authoriza- 
tion to access a service is propagated and is ultimately 

30 used gain access to the service in accordance with an 
embodiment of the present invention. The system starts 
at state 500 and proceeds to state 502. In state 502, 
server company 400 (from FIG. 4) creates server code 
460, which checks for clients being signed with key 

35 zero. Key zero is associated with a particular role, which 
defines a set of services that may be performed in the 
role. The system next proceeds to state 504. In state 
504, server company 400 creates for each client a new 
public/private key pair and a certificate. The system next 

40 proceeds to state 506. In state 506, server company 
400 exchanges these certificates and private keys with 
the clients. This exchange may involve a transfer of 
money in payment for the use of the service or some 
other contractual consideration. The system next pro- 

45 ceeds to state 508. 

[0031] In state 508, each client company optionally 
generates its own public/private key pairs and matching 
certificates for each client code module that is to 
assume the role represented by key zero. This process 

so may be repeated for numerous levels of clients and 
intermediaries until a final client that owns the client 
code is reached. The system next proceeds to state 
510. 

[0032] In state 510, the final client signs the client 
55 code with the last key in the chain and packages it with 
all certificates in the chain. The system next proceeds to 
state 512. In state 51 2, client code module 122 is down- 
loaded to a third party system 140, which also loads 
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server code module 1 12 from server company 400. The 
system then proceeds to state 51 4. 
[0033] In state 51 4, the client code requests access to 
the service stored by the server code by requesting a 
ticket for a role from the system. This role specifies cer- 
tain operations on the service. The system next pro- 
ceeds to state 516. In state 516, the system checks the 
validity of the request. This is done by examining all cer- 
tificates in the chain and the client code to ensure that 
the certificates and the client code are signed with the 
proper private keys. This is accomplished by using the 
corresponding public keys to verify signing by the corre- 
sponding private keys. If the request is valid, the system 
returns a ticket to the client. 

[0034] The process of examining the chain of certifi- 
cates may be carried completely by the server code, or 
completely by neutral code on the third party system. 
Alternatively, a portion of the examination can be car- 
ried out by the system code and a portion carried out by 
the neutral code. For example, the neutral code can 
examine all of the certificates except the first certificate, 
and the server code can examine the first certificate to 
verify that it is signed by private key zero. The system 
next proceeds to state 51 8. In state 51 8, the client code 
passes the ticket to server gate 202 (as was described 
above with reference to FIG. 2). Server gate 202 checks 
the validity of the ticket, and if valid, server gate 202 
sends to the client code a permit to access the service 
through the role. The system next proceeds to state 
522, which is an end state. The above-described proc- 
ess is repeated for each new server code module or cli- 
ent code module that the system desires to create. 
[0035] Note that the above-described process that 
produces a permit for the client code is not strictly nec- 
essary, and may be dispensed with in certain situations. 
If accesses to the service are infrequent, the desired 
access can simply be performed without giving the cli- 
ent code a permit for successive accesses. Additionally, 
the permit does not have be passive. It may include, 
among other things, a mechanism to inactivate the per- 
mit after a certain time period, and a mechanism that 
maintains a log of uses of the permit. It may also include 
mechanisms to ensure the permit has not been revoked 
and to identify users of the permit. 
[0036] The foregoing descriptions of embodiments of 
the invention have been presented for purposes of illus- 
tration and description only. They are not intended to be 
exhaustive or to limit the invention to the forms dis- 
closed. Many modifications and variations will be appar- 
ent to practitioners skilled in the art. 

Claims 

1. A method for providing a first computer program 
module (122) with an ability to access a service 
from a second computer program module (112), 
comprising: 



receiving the first computer program module 
(122); 

determining whether the first computer pro- 
gram module (122) has been digitally signed by 

s an authority (204) having power to confer 

access for the service from the second compu- 
ter program module (112); 
if the first computer program module (122) has 
been digitally signed by the authority (204) hav- 

10 ing power to confer access (212, 520) for the 

service, providing the first computer program 
module (122) with access to the service; and 
allowing the first computer program module 
(122) and the second computer program mod- 

15 ule (112) to run in the same address space on 

the same computing node, so that the first 
computer program module (122) can access 
the service from the second computer program 
module (112). 

20 

2, The method of claim 1 , wherein the act of determin- 
ing whether the first computer program module 
(122) has been digitally signed by the authority 
(204) having power to confer access for the service, 
25 includes using a public key associated with the 
service to verify that the first computer program 
module (122) has been digitally signed by a corre- 
sponding private key (312) for the service. 

30 3. The method of claim 1 or claim 2. wherein the act of 
determining whether the first computer program 
module (122) has been digitally signed by the 
authority having power to confer access for the 
service, includes verifying that the first computer 

35 program module includes a chain of certificates 
(310) establishing authorisation for the service, a 
first certificate (312) in the chain (310) being signed 
by an entity that is originally authorised to confer 
access for the service, and subsequent certificates 

40 (314-316) in the chain (310) being signed by enti- 
ties (430, 450) that have been delegated authorisa- 
tion to confer access (516) for the service. 

4. The method of any one of claims 1 to 3, wherein the 
45 act of providing the first computer program module 

(122) access to the service, includes providing 
(21 2) the first computer program module with a per- 
mit that allows the first computer program module 
(122) to perform a restricted set of services. 

50 

5. The method of any one of claims 1 to 4, wherein the 
service is accessed through an object defined 
within an object oriented programming system. 

55 6. The method of any one of claims 1 to 5, wherein the 
first computer program module (122) includes a 
Java Archive file. 
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7. The method of any one of claims 1 to 6, wherein the 
first computer program module (122) includes com- 
puter code (320) and at least one digital certificate 
(312, 314,316). 

8. The method of any one of claims 1 to 7, wherein 
providing the first computer program module (122) 
with access to the service allows the first computer 
program module (122) to interact with the second 
computer program module (112). 

9. The method of claim 8, wherein the first computer 
program module (122) originates from a first server 
(120) and is transferred (512) to a computer node 
(140) for execution, and the second computer pro- 
gram module (112) originates from a second server 
(110) and is transferred (51 2) to the computer node 
(140) for execution. 

10. The method of claim 8 or claim 9, wherein the first 
server (120) and the second server (110) computer 
are separately located from the computer node 
(140). 

11. The method of any one of claims 1 to 10, wherein 
the service includes a plurality of services. 

12. An apparatus that provides a first computer pro- 
gram module (122) with an ability to access a serv- 
ice from a second computer program module (112), 
comprising: 

a computer node (140); 
a receiving means, within the computer node, 
that receives the first computer program mod- 
ule (122); 

a verification means (204), within the computer 
node, that verifies that the first computer pro- 
gram module (1 22) has been digitally signed by 
an authority having power to confer access 
(21 2) for the service; 

an access means (202), within the computer 
node, that provides the first computer program 
module (122) with access to the service if the 
first computer program module has been digit- 
ally signed by the authority having power to 
confer access for the service; and 
an execution means, within the computer node 
(140), that allows the first computer program 
module (122) and the second computer pro- 
gram module (112) to run in the same address 
space on the same computing node, so that the 
first computer program module (122) can 
access the service from the second computer 
program module (112). 

13. The apparatus of claim 12, wherein the verification 
means (204) is configured to use a public key asso- 



ciated with the service to verify that the first compu- 
ter program module (122) has been digitally signed 
by a corresponding private key for the service. 

5 14. The apparatus of claims 1 2 or 1 3, wherein the veri- 
fication means is configured to verify that the first 
computer program module (122) includes a chain of 
certificates (310) establishing authorisation for the 
service, a first certificate (312) in the chain (310) 

10 being signed by an entity that is originally author- 
ised to confer access for the service, and subse- 
quent certificates (314-316) in the chain (310) 
being signed by entities that have been delegated 
authorisation to confer access for the service. 

15 

15. The apparatus of any one of claims 12 to 14, 
wherein the access means (202) is configured to 
provide the first computer program module (122) 
with a permit that allows the first computer program 

20 module (122) to perform a restricted set of services. 

16. The apparatus of any one of claims 12 to 15, 
wherein the service is accessed through an object 
defined within an object oriented programming sys- 

25 tern. 

17. The apparatus of any one of claims 12 to 16, 
wherein the first computer program module (122) 
includes a Java Archive file. 

30 

18. The apparatus of any one of claims 12 to 17, 
wherein the first computer program module (122; 
432; 434; 436; 452) includes computer code and at 
least one digital certificate (404; 408; 412; 416; 

35 424). 

19. The apparatus of any one of claims 12 to 18, 
wherein the receiving means is configured to trans- 
fer the first computer program module (122) from a 

40 first server (120), and to transfer the second com- 
puter program module (112) from a second server 
(110). 

20. The apparatus of claim 19, wherein the first server 
45 (110) and the second server (120) are separate 

from the computer node (140). 

21 . The apparatus of claims 1 9 or 20, wherein the serv- 
ice includes a plurality of services. 

50 

22. A computer readable storage medium storing 
instructions that when executed by a computer 
cause the computer to perform a method for provid- 
ing a first computer program module (122) with an 

55 ability to access a service from a second computer 
program module (112), comprising; 

receiving the first computer program module 
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(122); 

determining whether the first computer pro- 
gram module (122) has been digitally signed by 
an authority (400) having power to confer 
access for the service from the second compu- 5 
ter program module (1 1 2); 
if the first computer program module (122) has 
been digitally signed by the authority (400) hav- 
ing power to confer access (212, 520) for serv- 
ice, providing the first computer program 10 
module with access to the service; and 
allowing the first computer program module 
(122) and the second computer program mod- 
ule (112) to run in the same address space on 
the same computing node (140), so that the 15 
first computer program module (122) can 
access the service from the second computer 
program module (112). 

23- A computer program module or Java applet (122) 20 
which is able to access a service from a second 
computer program module, comprising; 

a computer code section (320), including com- 
puter code for execution on a computr node to 25 
carry out functions of the first computer pro- 
gram module; and 

a digital signature section (310), including a 
chain of certificates establishing authorization 
for the service, a first certificate (312) in the 30 
chain being signed by an entity that is originally 
authorized to confer access for the service, and 
subsequent certificates (314,316) in the chain 
being signed by entities that have been dele- 
gated authorization to confer access for the 36 
service, the digital signature section allowing 
the computer node to determine whether the 
computer program module has been granted 
authority to access the service. 

40 

24- A computer program encoding a set of computer 
instructions for facilitating the provision of a first 
computer program module (122) with an ability to 
access a service from a second computer program 
module (112), which when running or a computer is 45 
adapted to perform the method as claimed in any 

on of the claims 1 to 1 1 . 
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